1. Field
The invention relates to a method of connecting applications to applications, hardware to hardware, and applications to hardware, and a distributed architecture system for facilitating modular communication between a plurality of applications, a plurality of devices, and a plurality of applications and devices.
2. Background
Today's Test and Measurement systems are monolithic in nature where a given system supports at most a handful of closely related, tightly integrated stimulus and measurement capabilities. Systems take on the personality and characteristics of the specific stimulus and measurement capability and are limited to supporting this personality and characteristics. Even systems which are designed on a modular platform are truly monolithic in nature where only a given set of closely related, tightly integrated capabilities can be supported at a given time. To support a different capability, the modular system must transform to this new capability completely. Often systems have to be powered down and re-powered back up so that the monolithic software can install the specific drivers for the installed hardware capability.
Today's monolithic, non-distributed systems limit the ability of the user to support different measurement and stimulus capabilities simultaneously. These solutions also require a tight coupling, typically through direct hardware connection. The exposure of the stimulus and measurement capability through a User Interface is tightly coupled with the actual stimulus and measurement hardware. The User Interface is also heavily integrated with the system software. Even if the User Interface is created as a separate Application Layer, it is tightly coupled with the system software, the system hardware, and the module hardware. The module driver is also heavily integrated with the system software. This is clearly shown in those situations where the system must be fully restarted when the module is changed so the new personality and the new module driver can be loaded specifically. With today's systems, a user cannot test their entire system unless that system is covered by the handful of closely related, tightly integrated stimulus and measurement capabilities.
As an example, customers often wish to test a complete communication network path crossing the fiber optic/copper boundary. They want to measure the transmission characteristics and signal parameters on the fiber component of the network and also measure the transmission characteristics and signal parameters on the copper component of the network. Today, a customer would have to either have two completely different units—one configured as a fiber test platform and one configured as a copper fiber test platform (assuming a modular platform). It may be very expensive to have two complete modular systems. Otherwise, if the customer wants to control costs, the customer needs to configure their modular system as a fiber tester, test the fiber component and then reconfigure their modular system to a copper tester and test the copper component. This increases test time. This also increases opportunity for both false failures and false positives.
Today's monolithic software architectures are also specifically designed for a given hardware base. They are designed to run on a given Operating System (ex. Windows or Linux) but also on a custom designed set of hardware made up processor, memory, support peripherals, storage, and communication. To support movement to a different hardware base, the software would need to be redesigned and re-architected as it is tightly integrated with the hardware it runs on. Though a new processor of similar capability can be designed into their hardware base, a wholesale change to a different hardware base, or a different Operating System is not possible due to the closely integrated nature of their system design.